Не так давно мы писали о том, что обновилась бета-версия решения StarWind SAN V8 (это было сделано неофициально), предназначенного для создания отказоустойчивых iSCSI-хранилищ для виртуальных машин. На днях же была выпущена обновленная официальная версия - StarWind SAN V8 Beta 3.

Напомним сначала основные новые возможности StarWind V8:

• L2 Flash Cache - кэш уровня L2, который работает непосредственно с кэшем уровня L1 в RAM, что существенно улучшает производительность.
• Файловая система LSFS, которая изначально работает с большими блоками данных, что положительно сказывается на сроке службы флеш-накопителей (SSD), на которых размещаются виртуальные машины (это дело недалекого будущего). Файловая система LSFS преобразовывает small random writes в большие последовательные операции записи, что также существенно увеличивает производительность.
• Inline-дедупликация StarWind, которая не создает нагрузку на подсистему хранения и не "крадет" IOPS'ы у продуктивного хранилища.
• Simplified and improved GUI - улучшенный интерфейс мастеров развертывания хранилищ для Windows Server 2012 с поддержкой скриптов PowerShell.
• Возможность интеграции с механизмом SMI-S для Windows Server 2012 R2.
• Massive Scale-Out storage architecture - возможность масштабирования узлов кластера хранилищ до любого числа (а не только 3 как сейчас).
• Asynchronous WAN-replication - возможность асинхронной репликации между узлами и возможность создания катастрофоустойчивого решения для хранилищ.
• Поддержка примитивов VAAI для устройств на одном узле и устройств с синхронной репликацией: поддерживаются команды WRITE SAME, EXTENDED COPY, ATS.
• Репликация конфигурации узла, включая информацию о снапшотах, что позволяет в случае сбоя сохранить созданную оригинальную конфигурацию и реплицировать ее уже, например, на третий узел.

А вот какие улучшения появились в предрелизной версии StarWind SAN V8 Beta 3 (по сравнению с прошлой "неофициальной" бета-версией):

Улучшения устройств LSFS

• Обработка размера устройства и его заполненности напрямую от нижележащего физического устройства.
• Исправлен баг, приводивший к ошибкам записи на диск

Синхронная репликация устройств LSFS

• Пофикшены ошибки при работе со снапшотами (удаление и создание).
• Поправлена ошибка, когда один из HA-узлов почему-то выпадал в состояние "unsynchronized".

VSS-провайдеры для поддержки устройств с LSFS

• Hardware VSS provider - теперь доступен для LSFS-устройств, в том числе с синхронной репликацией.
• Software VSS Provider - доступен для обычных LSFS-устройств.

Asynchronous WAN-replication - возможность асинхронной репликации между узлами и возможность создания катастрофоустойчивого решения для хранилищ.

• Теперь возможна репликация даже на очень медленных каналах.
• Пофикшено монтирование снапшотов.
• Улучшен алгоритм репликации.
• Небольшие доработки в механизме поддержки VAAI.

Скачать новую StarWind SAN V8 Beta 3 можно по этой ссылке. Release notes доступны тут.

Гипервизор в составе лицензируемого Windows Server с самого начала существует в бесплатном варианте Hyper-V Server. Этот продукт включает в себя весь необходимый набор функций полноценной серверной платформы виртуализации, включающих поддержку Failover Cluster, RemoteFX и виртуальных машин Gen 2. Однако администратора после установки ожидает сюрприз в виде вот такого синего окошка:

Интересный наброс произошел некоторое время назад в среде виртуализаторов. Оказывается, что Microsoft Exchange 2013 (который станет одним из главных почтовых серверов в ближайшем будущем) не поддерживается для размещения его в виде виртуальной машины на томах NAS / NFS. Вот такая штука - многие используют, а не знают, что это не поддерживается.

При этом NAS-хранилища SMB 3.0, появившиеся в Windows 8 и Windows Server 2012, вполне себе поддерживаются. Напомним, что NFS-протокол используют хранилища таких производителей, как Tintri, Maxta, NetApp и Nutanix.

Об этом всем можно прочитать в официальном документе "Exchange 2013 Virtualization" на TechNet:

All storage used by an Exchange guest machine for storage of Exchange data must be block-level storage because Exchange 2013 doesn't support the use of network attached storage (NAS) volumes, other than in the SMB 3.0 scenario outlined later in this topic. 

То есть, данные Exchange (почтовые ящики, очереди и т.п.) должны храниться только на блочных хранилищах SCSI или iSCSI (block-level storage), а для файловых хранилищ, кроме SMB 3.0, поддержки нет.

В статье "NFS and Exchange - not a good combination" эксперт по инфраструктуре Microsoft Exchange Тони Рэдмонд раскрывает причину такого явления - дескать, все дело в механизме ESE (Extensible Storage database engine), используемом сервером Exchange. Блочное хранилище на базе протокола SCSI поддерживает обязательный сброс транзакции в случае сбоя, а вот файловое хранилище обеспечивает этот сброс "по мере возможности".

Для тех, кто недоволен ситуацией есть вот такая голосовалка "Support storing exchange data on VMDKs on file shares(nfs/smb)", где можно не только отдать свой голос за поддержку файловых хранилищ, но и пообщаться с экспертами на эту тему.

Роман, а вы что скажете? Когда у Exchange будет поддержка NFS, и не надо будет кастомерам рассказывать об использовании NetApp в блочном режиме?

Раньше пользователи думали о том, как нужно развертывать VMware vCenter - в виртуальной машине или на физическом сервере. Теперь время этих размышлений прошло - большинство ставит его в виртуальной машине. Однако с появлением готового модуля vCenter Server Appliance (vCSA) встал немного другой вопрос - использовать ли готовый vCSA или устанавливать vCenter в Windows. Попробуем разобраться.

Продолжаем рассказывать о решении StarWind iSCSI SAN, предназначенном для создания отказоустойчивых iSCSI-хранилищ для виртуальных машин. Напомним, что если вы используете решение для VMware, то в нем есть функции по дедупликации данных виртуальных хранилищ (в том числе, для Veeam Backup and Replication), которые позволяют существенно сократить затраты на приобретение дисковых емкостей. Это актуально для плагина резервного копирования хранилищ StarWind VMware Backup Plug-in.

На сайте StarWind вы можете посчитать, сколько именно позволяет экономить механизм дедупликации от StarWind, используя русскоязычный калькулятор "Калькулятор окупаемости технологии Дедупликации":

Интересная штука тут нашлась у партнера VMware - компании CloudVolumes. Эти ребята придумали распространять виртуализованные приложения VMware ThinApp в виде дисков VMDK, которые можно подцепить к виртуальным машинам, предоставляя тем самым ее пользователям доступ к данному приложению. Называется это решение CloudVolumes ThinApp Edition.

Схематично это выглядит таким образом - CloudVolumes выступает как брокер, который отвязывает и привязывает VMDK-диски к виртуальным машинам, учитывая правила доступа, которые задаются на уровне пользователей и групп Active Directory:

Как только виртуальный диск VMDK привязан, приложение появляется у пользователя в виртуальной машине, как будто бы оно у него локально установлено. То есть, это в основном решение для VDI-инфраструктуры на базе VMware Horizon View.

Такая модель распространения виртуальных приложений ThinApp обладает следующими преимуществами:

• Гибко и в рамках виртуальной инфраструктуры - VMDK можно просто положить на общее виртуальное хранилище, не нужны дополнительные средства для инъекций пакетов ThinApp в виртуальные ПК.
• Один диск VMDK в шаренном режиме можно подключить сразу к нескольким виртуальным машинам (в режиме только для чтения).
• Простота обновлений - можно просто заменить VMDK или отключить его.
• Производительность - работает быстрее, чем запускать приложения с файловой шары, и не задействует сеть Ethernet.
• Удобство управления - есть интеграция с AD, которая позволяет назначать VMDK с приложениями пользователям и группам из единой консоли.

Вот сравнение по времени запуска приложения с диска VMDK с методом запуска из файловой шары:

Больше интересного об этом решении можно узнать из этого документа: "Enhanced Management and Performance of VMware ThinApp Virtual Applications with CloudVolumes Shared VMDKs".

Компания NetApp представила свои новые аппаратные платформы, отвечающие требованиям к производительности приложений, работающих с большими объемами данных. Представленные обновления полностью соответствуют инновационной стратегии NetApp, направленной на разработку ускоренных при помощи флэш-технологий и интегрируемых в облачные архитектуры решений хранения данных для широкого спектра разделяемых и специализированных ИТ-инфраструктур. Более подробно узнать о решениях NetApp, протестировать и заказать их можно на сайте компании ИТ-ГРАД.

Флеш-массив NetApp EF550

Массив NetApp EF550 Flash Array разработан для высокопроизводительных приложений, допустимое время ожидания для которых исчисляется долями миллисекунды.

Флэш-массив NetApp EF550® обеспечивает исключительную производительность, эффективность ИТ и надежность для критически важных приложений, увеличивая скорость их работы и сокращая время ожидания.

СХД корпоративного класса NetApp EF550 на базе дисков SSD позволяет:

• ускорить процессы бизнеса благодаря времени отклика, составляющему всего доли миллисекунды;
• устранить избыточное выделение ресурсов и повысить эффективность ИТ;
• добиться операционной производительности, эквивалентной работе 1000 традиционных дисков (15 000 об/мин), используя корпус 2U, который задействует всего 5% пространства стойки, ресурсов питания и охлаждения;
• быстро определять и устранять возможные проблемы с помощью расширенных возможностей мониторинга и проактивного устранения неисправностей;
• обеспечить защиту от потери данных и устранить простои благодаря копиям NetApp Snapshot, удаленной репликации и прочим функциям защиты данных;
• выполнять репликацию данных на СХД EF550 или NetApp E-Series;
• воспользоваться преимуществами корпоративной программной платформы ПО SANtricity.

Высокие показатели IOPS, время ожидания, составляющее всего доли миллисекунды, возможность масштабирования и надежность корпоративного класса флэш-массива NetApp EF550 позволяют ускорить выполнение рабочих процессов и быстрее получить желаемые результаты.

Обновления E-Series – E2700 и Е5500

E-Series включена в линейку решений NetApp для блочных систем хранения данных с повышенной производительностью. Системы E-Series легко масштабируются и предназначены для рабочих нагрузок, требующих 99,999% надежности при устойчиво высокой производительности. 

Новый массив хранения данных NetApp E2700 SAN

Масштабируемая NetApp E2700 представляет собой решение общего назначения для хранения данных приложений, которое подходит для филиалов, удаленных офисов и предприятий среднего бизнеса. На выбор доступны три вида полок — 4U/60, 2U/24 и 2U/12, а также три интерфейса для подключения: FC, iSCSI или SAS. E2700 интегрируется с основными приложениями, включая системы VMware, Exchange, SQL и Oracle.

NetApp E2700 позволяет:

• добиться высочайшего в своем классе уровня производительности для широкого ряда баз данных и других транзакционных приложений;
• упростить и снизить затраты на управление данными с высокой пропускной способностью с помощью конфигурируемой архитектуры, простой в использовании и установке;
• оптимизировать производительность, сократить время ожидания, увеличить пропускную способность и показатель IOPS;
• обеспечить бесперебойность операций с помощью гибкой интеграции приложений;
• масштабировать дисковое пространство по мере роста предприятия.

Как и другие NetApp E-Series, E2700 использует надежное, простое в использовании и экономичное ПО для управления СХД SANtricity.

Это программное обеспечение позволяет повысить уровень производительности и эффективности, обеспечивает динамическое распределение дисковых ресурсов и управление RAID, а также включает в себя технологию Intelligent Cache Tiering (разделение уровней хранения с помощью интеллектуального кэширования) и расширенные возможности защиты данных, в том числе репликацию и аварийное восстановление данных.

Высокопроизводительная система E5500 расширяет возможности защиты данных благодаря использованию инструментального пакета SANtricity с функциями репликации данных и гибким интерфейсом. Система предлагается с дисками iSCSI объемом 10 Гбайт и дисками FC объемом 16 Гбайт.

Программа NetApp AutoSupport обеспечивает пользователям возможность контроля всего предприятия и содержит встроенные средства аналитики для проактивного управления. E5500 может поддерживать объем памяти до 1,5 Пбайт на одну систему, необходимый для крупномасштабных систем обработки данных.

За консультацией по данному оборудованию обращайтесь в компанию ИТ-ГРАД.

Продолжаем рассказывать о решении StarWind iSCSI SAN, предназначенном для создания отказоустойчивых iSCSI-хранилищ для виртуальных машин (есть версия как для VMware, так и для Hyper-V).

Цена
Программное обеспечение от StarWind обойдется намного дешевле аналогичных аппаратных решений. Если же со временем объем хранилища нужно будет увеличить, со ПО StarWind вы сэкономите еще больше средств. Стоимость продукта можно запросить по этой ссылке.

Функциональность
Функциональные возможности StarWind ни в чем не уступают дорогостоящим высокопроизводительным системам хранения данных. StarWind делает технологии корпоративного уровня доступными для небольших предприятий. Такие полезные функции, как высокая доступность, горизонтально-масштабируемое NAS-хранилище, асинхронная репликация по WAN и дедупликация являются встроенными и не требуют дополнительных лицензий.

Надежность
В отличие от аппаратных решений, надежность и эффективность технологий StarWind можно легко проверить. Просто установите 30-дневную пробную версию ПО StarWind и самостоятельно оцените его производительность и функциональность.

Универсальность
StarWind «не привязывает» пользователя к конкретному аппаратному обеспечению и предлагает решения, работающие на любом оборудовании. Поломка сервера не приведет к длительному простою, потому что вместо него можно быстро подключить другую машину. В то же время, замена специализированного устройства хранения может потребовать много времени.

Масштабируемость
Частичная или полная замена оборудования - не помеха для работы StarWind. Объем хранилища данных можно легко расширить, подключив новый сервер и используя уже имеющиеся лицензии на операционные системы и ПО StarWind.

На днях компания Red Hat обновила свои решения для создания инфраструктуры виртуализации и управления облачной инфраструктурой. Итак, во-первых, обновилась платформа виртуализации на базе гипервизора KVM - Red Hat Enterprise Virtualization (RHEV) 3.3.

Напомним, что прошлая версия RHEV 3.1 вышла больше года назад, а именно, в декабре 2012 года, затем была версия RHEV 3.2 в октябре прошлого года, ну а нынешнее обновление также является весьма существенным. Одно из интересных нововведений версии RHEV 3.3 - поддержка архитектуры OpenStack (в рамках Technology Preview), которая позволяет архитекторам использовать такие компоненты, как Nova (контроллер вычислительных ресурсов) и Cinder (облачные блочные хранилища). Напомним, что недавно о поддержке OpenStack объявила компания VMware.

Новые возможности Red Hat Enterprise Virtualization 3.3:

• Функции портала администрирования:
  • Бонды (тимы) могут быть сформированы путем перетаскивания интерфейса в бонд и наоборот.
  • Добавлена кнопка создания снапшота (Create Snapshot)
  • Плагин Red Hat Support plug-in для создания кейса в техподдержку
• Инфраструктурные возможности:
  • Техническое превью поддержки средств управления OpenStack Foreman
  • Интеграция с Cloud-init
  • Роль Storage Pool Manager может быть вручную назначена и переназначена хостам
  • Поддержка Trusted Compute Pools, основанная на проекте OpenAttestation
  • Оптимизация технологии Memory balloon и сообщений об ошибках
  • Виртуальное устройство watchdog
  • Приоритеты для CPU sharing
• Функции для разработчиков
  • API для резервного копирования и восстановления ВМ
  • API для планировщика виртуальных машин
• Сетевые функции
  • Улучшения процесса настройки Management network
  • Роль миграции сети
  • Кастомные свойства адаптеров vNIC
  • QoS для профилей устройств vNIC
  • Несколько сетевых шлюзов на хост
  • Новый пакет python-inotify
  • Возможность рефреша конфигурации сети для хоста
  • Улучшенная поддержка бондинга (тиминга) адаптеров
  • Поддержка провайдера OpenStack Neutron
• Квоты
  • Возможность управления квотами
• Возможности хранилищ
  • Поддержка Virtio-SCSI
  • Поддержка GlusterFS
• Портал пользователя
  • Поддержка нескольких мониторов на одном устройстве QXL
• Функции протокола SPICE
  • Поддержка технологии SPICE-HTML5

Помимо Red Hat Enterprise Virtualization (RHEV) версии 3.3 компания Red Hat также выпустила версию 4.0 своего IaaS-решения, основанного на архитектуре OpenStack: Red Hat Cloud Infrastructure.

Инфраструктура Red Hat Cloud Infrastructure состоит из следующих компонентов:

• Red Hat Enterprise Virtualization
• Red Hat Enterprise Linux OpenStack Platform
• Red Hat CloudForms (управление и оркестрация - то есть автоматизация задач)

Более подробно об этом можно почитать по этой ссылке.

Не так давно мы писали о новой версии продукта 5nine Manager for Hyper-V 3.7, который предоставляет локальный графический интерфейс пользователя (GUI) для Windows Server и Windows Server Core, а также для бесплатного Hyper-V Server. Этот продукт позволяет одновременно управлять гипервизором Microsoft Hyper-V различных версий (2012 R2 / 2012 / 2008 R2 SP1). Совсем недавно (в январе этого года) вышла версия 5nine Manager for Hyper-V 3.9.
Таги: 5nine, Manager, Update, Hyper-V, Storage

Калькулятор для расчета необходимой дисковой емкости под кластер VMware Virtual SAN (VSAN).

Мы довольно много пишем про кластеры хранилищ VMware Virtual SAN (VSAN), которые создаются на базе локальных дисков серверов VMware ESXi (например, тут и тут, а в последний раз - тут). А сегодня мы хотим рассказать о калькуляторе, который может пригодиться для расчета необходимой емкости хранилищ под Virtual SAN.

Написал его Duncan Epping, известный специалист по VMware vSphere и блоггер - один из немногих, которому можно верить.

Калькулятор рассчитывает общее количество требуемого дискового пространства (HDD и SSD-диски) как для кластера в целом, так и для одного хоста VMware ESXi, принимая в качестве исходных данных следующие параметры:

• Количество ВМ в кластере хранилищ.
• Объем оперативной памяти машины (vRAM).
• Размер виртуального диска машины.
• Число хостов, используемое для построения кластера.
• Параметр Failures to tolerate (о нем мы писали тут).
• Процент дискового пространства на метаданные и прочие издержки виртуализации хранилищ (по лучшим практикам - где-то 10%).
• Процент пространства, которое занимает SSD-накопитель от дискового пространства на базе HDD-дисков хоста ESXi.

Поиграть с калькулятором дискового пространства для Virtual SAN можно по этой ссылке.

Компания StarWind, лидер в разработке решений для создания программных отказоустойчивых iSCSI-хранилищ для виртуальных машин, провела серию вебинаров вместе с Microsoft Украина на русском языке на тему программных хранилищ данных в Windows Server 2012.

В рамках онлайн сессии Microsoft, Юрий Хохлов, ведущий инженер-программист компании StarWind Software, рассказал о iSCSI Target и SMI-S от компании StarWind, а также рассмотрел некоторые тонкости, которые могут быть полезными в рабочей среде.

Все это теперь доступно в записи. Первая часть выступления касается следующих моментов:

• Обзор базовой работы с дисками
• Динамические диски
• Обзор типов томов, которые можно построить в Windows Server
• Создание программных рейдов
• Организация Storage Spaces в Windows Server 2012 R2
• Управление внешними хранилищами на примере Windows Server 2012 R2 + StarWind

Во второй части записи онлайн-трансляции можно узнать о таких подробностях работы хранилищ, как:

• Обзор файловых систем
• Свойства NTFS
• Работа с квотами
• Линкование
• File Server Resource Manager
• Теневое копирование

В ближайшее время будут еще вебинары, так что не отключайтесь.

Более подробно о сотрудничестве компании StarWind и Microsoft Украина можно почитать тут. Пробная версия продукта StarWind Native SAN for Hyper-V доступна по этой ссылке - http://ru.starwindsoftware.com/native-san-for-hyper-v.

Ну и напомним последние новости о новой версии StarWind V8, выпуск которой ожидается в ближайшее время.

Мы уже немало писали про кластеры хранилищ VMware Virtual SAN (последнее - тут и тут), а сегодня рассмотрим механизм работы запросов на чтение блоков, который описал в своем блоге Duncan Epping.

Итак, схема кластера VMware Virtual SAN:

Здесь мы видим такую картину - виртуальная машина находится на хосте ESXi-01, а ее блоки размером 1 МБ размещаются на хранилищах разных хостов. При этом блоком 1 владеет ESXi-01, а блоком 2 - ESXi-03. Хост ESXi-02 не принимает участия в обработке запросов ввода-вывода.

Схема работы запроса на чтение проста - сначала проверяется наличие блока в кэше на чтение (Read cache), и если там блока не оказывается, то проверяется Write buffer на хранилище SSD (если блок еще не успел записаться на HDD) и непосредственно сам HDD-диск. В данном случае блок 1 нашелся на SSD-диске в кэше на чтение.

Второй же блок обслуживается хостом ESXi-03, но его не оказалось в кэше на чтение, и он читается с HDD-диска. Тут надо отметить, что кластер Virtual SAN помещает блоки в кэш на чтение только на тех хостах, которые активно обслуживают этот блок и владеют им, а те хосты, которые просто хранят копию данных - в Read cache таких блоков не помещают.

Не так давно мы писали о том, что компания VMware выпустила виртуальный модуль VOVA (vSphere OpenStack Virtual Appliance), предназначенный для интеграции с архитектурой OpenStack, которая представляет собой комплекс проектов свободного программного обеспечения, предназначенного для построения облачной инфраструктуры.

На днях же VMware выпустила небольшой документ "Getting Started with OpenStack and VMware vSphere", в котором описывается схема того, как использовать решение vSphere в качестве бэкэнда для компонентов Nova (контроллер вычислительных ресурсов) и Cinder (облачные блочные хранилища).

В указанном руководстве все опирается на виртуальный модуль VOVA с Linux-машиной, которая реализует все необходимые сервисы OpenStack.

Структура документа:

• Introduction
  • VMware vSphere
  • OpenStack
  • Using OpenStack with vSphere
    • OpenStack and vSphere: Conceptual Analogies
  • The VMware OpenStack Virtual Appliance
• Requirements
  • vSphere Requirements
    • vSphere Inventory: Single Datacenter
    • Cluster: Automated VMware vSphere Storage DRS
    • Storage: Shared
    • Networking
      • Port Groups and VLANs
      • ESXi Firewall
      • DHCP Server
• Installation
  • Importing VOVA
  • Configuring VOVA
  • Starting VOVA
  • Configuring the VMware vSphere Web Client Plug-in for OpenStack
• Managing OpenStack with the Horizon Web Interface
  • Logging In – Web
  • Logging In – SSH/CLI
  • Flavor of the Day
  • Launching an Instance
  • Accessing the Console for an Instance
  • Managing Storage
    • Adding Persistent Storage to an Instance
    • Removing Persistent Storage from an Instance
    • Adding the Persistent Storage to Another Instance
  • Network

Надо отметить, что виртуальный модуль VOVA официально не поддерживается со стороны VMware и предоставляется "as is".

Продолжаем рассказывать об услугах компании ИТ-ГРАД - первого сервис-провайдера в России, предоставляющего в аренду виртуальные машины на платформе VMware.

Помимо услуг IaaS (Infrastructure-as-a-Service) компания ИТ-ГРАД занимается поставкой уже готовых комплексов для создания виртуальной инфраструктуры. Комплексы укомплектованы всем необходимым для начала работы и не требуют дополнительного оборудования. Опциональные возможности позволяют легко наращивать производительность любого комплекса, либо изменять его качественные характеристики.

Предлагаемые решения являются результатом многолетнего опыта компании по построению инфраструктуры приватных облаков на базе продуктов VMware. Все применяемые компоненты одобрены к использованию компанией VMware для построения виртуального датацентра на базе VMware vSphere 4.1 и выше. Все комплексы полностью протестированы в Центре Компетенции, и ИТ-ГРАД гарантирует их работоспособность и эффективность.

*-без учета Storage Efficiency

Более подробно узнать о составе и функциях облачных комплектов от ИТ-ГРАД, а также ознакомиться с возможностями комплекта для построения инфраструктуры 3D VDI, можно по этой ссылке.

Продолжаем рассказывать о решении StarWind iSCSI SAN V8, предназначенном для создания отказоустойчивых iSCSI-хранилищ для виртуальных машин. Не так давно мы о новых возможностях второй беты продукта StarWind V8, а в первых числах этого года появилась обновленная (третья) бета этого продукта, которую можно скачать по этой ссылке: http://www.starwindsoftware.com/starwind-v8-beta.

Напомним основные новые возможности StarWind V8 Beta 3:

• L2 Flash Cache - кэш уровня L2, который работает непосредственно с кэшем уровня L1 в RAM, что существенно улучшает производительность.
• Файловая система LSFS, которая изначально работает с большими блоками данных, что положительно сказывается на сроке службы флеш-накопителей (SSD), на которых размещаются виртуальные машины (это дело недалекого будущего). Файловая система LSFS преобразовывает small random writes в большие последовательные операции записи, что также существенно увеличивает производительность.
• Inline-дедупликация StarWind, которая не создает нагрузку на подсистему хранения и не "крадет" IOPS'ы у продуктивного хранилища.
• Simplified and improved GUI - улучшенный интерфейс мастеров развертывания хранилищ для Windows Server 2012 с поддержкой скриптов PowerShell.
• Возможность интеграции с механизмом SMI-S для Windows Server 2012 R2.
• Massive Scale-Out storage architecture - возможность масштабирования узлов кластера хранилищ до любого числа (а не только 3 как сейчас).
• Asynchronous WAN-replication - возможность асинхронной репликации между узлами и возможность создания катастрофоустойчивого решения для хранилищ.
• Поддержка примитивов VAAI для устройств на одном узле и устройств с синхронной репликацией: поддерживаются команды WRITE SAME, EXTENDED COPY, ATS.
• Репликация конфигурации узла, включая информацию о снапшотах, что позволяет в случае сбоя сохранить созданную оригинальную конфигурацию и реплицировать ее уже, например, на третий узел.

Некоторым администраторам может понадобиться информация о том, как узнать LUN ID в Windows Server 2012 R2, например, при создании отказоустойчивого кластера на платформе Hyper-V (Failover cluster).

Делается это просто. Запускаем cmd и открываем diskpart:

Смотрим подключенные устройства командой:

list disk

Выбираем нужный LUN командой:

select disk <number>

Смотрим свойства устройства, где и показан LUN ID, командой:

detail disk

Ну что же, наступил 2014 год, и самое время поговорить о том, что нас ждет в ближайшем будущем. Точнее говоря, лучше почитать, что говорят об этом крупные компании, принимающие участие в производстве средств виртуализации и сопутствующих решений.

Традиционно, Дэвид Маршал собирает их на ресурсе vmblog.com, где размещено больше сотни прогнозов на 2014 год, как от крупных игроков рынка, так и от малоизвестных нишевых компаний. Ниже мы приведем ссылки на наиболее интересные прогнозы с их краткими аннотациями.

VMware 2014 Predictions: Virtual Crystal Ball Gazing

CTO компании VMware, Paul Strong, рассказывает о том, что самым важным элементом инфраструктуры предприятий являются приложения. Вся остальная часть инфраструктуры должна быть упрощена и автоматизирована, что логично, так как вся техническая ИТ-инфраструктура создана только для одного - поддерживать приложения.

Как таковых прогнозов в статье не много, но вот, о чем говорит нам CTO:

• Виртуализация будет распространятся на все корпоративные приложения, включая самые критичные и высоконагруженные.
• Компании будут внедрять технологии Network Virtualization для создания эффективных распределенных сетей (см. решение VMware NSX и концепцию Software-defined networking).
• Начнутся внедрения решения Virtual SAN (VSAN), позволяющего строить распределенные кластеры хранилищ на базе локальных дисков хост-серверов.
• Произойдет очень серьезное расширение инфраструктуры гибридных облаков.

Приоритеты VMware остаются прежними:

• Software-Defined Data Center - концепция программно-определяемого датацентра.
• Hybrid Cloud - гибридное облако между инфраструктурой предприятия и публичными датацентрами VMware vCHS.
• End User Computing - технологии повышения эффективности работы конечных пользователей.

Citrix 2014 Predictions: 2014 will not be the year of VDI

Прогнозы Citrix выходят под очень провокационным заголовком, поскольку компания в прошлом году провозглашала его как год VDI, то есть повсеместного внедрения виртуализации настольных ПК.

Что же Citrix имеет в виду теперь? На этот раз тут имеется в виду, что рынку нужно нечто большее, чем просто виртуализация настольных ПК - нужно менять парадигму, касающуюся работы пользователей в современном мобильном мире. Во всю развиваются гибридные облака и сервис-провайдеры, предоставляющие не только серверы, но и десктопы в аренду (DaaS, Desktop-as-a-Service). Пользователи хотят использовать свои собственные устройства для работы в корпоративной инфраструктуре (концепция BYOD). Корпоративной инфраструктуре нужны единые, гибкие и эффективные средства управления.

То есть нужно адаптировать корпоративную ИТ-инфраструктуру под меняющиеся реалии - облачную моду и мобильность пользователей. Вот на это будет делать ставку Citrix, а также и на то, чтобы сделать необходимые средства для управления облачной средой, которые у Citrix, увы, еще пока не так хороши, как хотелось бы.

Кроме того, вот тут Citrix дает и более конкретные прогнозы по инфраструктуре предприятий:

• Количество пользовательских устройств BYOD увеличится на 25%.
• 70% предприятий поддерживают или добавят поддержку Android OS, поскольку именно Андроид будет рулить в корпоративной инфраструктуре, а не iOS.
• Более половины созданного контента в корпоративной среде будет создано на мобильных платформах, основная коммуникация также будет происходить с мобильных устройств.

Red Hat 2014 Predictions - Promise Turned Into Reality: Enterprise IaaS Adoption in 2014

Компания Red Hat считает, что в 2014 году многие компании в рамках стратегии по аренде виртуальных машин в облаке (Infrastructure as a Service, IaaS) перейдут от размышлений к действию, и многие будут использовать для этого сервис-провайдеров на платформе OpenStack, ведь у Red Hat есть собственный дистрибутив RDO в раках этой архитектуры.

Само собой, Red Hat верит в публичные облака на базе Open Source решений, поскольку сама является их разработчиком (например, гипервизора KVM). Ну и ставку Red Hat делает, прежде всего, на экосистему партнеров, поскольку не имеет собственного публичного облака.

Oracle 2014 Predictions: The Rise of Ready-Made IT

Oracle в своих прогнозах также придерживается идеи всеобщей "мобилизации" - корпоративные пользователи будут работать с планшетов (причем своих), BYOD станет всеобщим, а пользователи будут получать доступ к приложениям через браузер с поддержкой HTML 5.

С точки зрения построения корпоративной инфраструктуры, Oracle считает, что она должна направляться приложениями, то есть все средства виртуализации должны быть, прежде всего, заточены под приложения и быть у них на службе. Неудивительно, ведь Oracle является одним из самых известных разработчиков СУБД, при этом как производителя платформ виртуализации ее мало кто знает.

Если, конечно, не брать в расчет настольную платформу VirtualBox, обновления которой мы, несомненно, увидим в следующем году.

Ну и, конечно, же Oracle верит в конвергентную инфраструктуру, стандартизированную и собираемую из готовых блоков (программных и аппаратных), таких как сервера приложений, БД и прочие сервисы, развертываемые по требованию из уже готовых шаблонов. Хотя тут позиции Oracle и не очень сильны.

Veeam 2014 Predictions - Forget virtual first, now it's virtual only!

Рик Вановер из компании Veeam считает, что этот год для многих компаний будет годом 100%-й виртуализации, то есть все приложения так или иначе будут перенесены в виртуальную среду. Более того, именно высокий, определенный в организации, процент виртуализованных систем, считает Рик, должен стать целевым показателем, к которому должны стремиться компании.

Еще интересные прогнозы:

• HyTrust 2014 Predictions - Cloud Security in 2014
• Virtual Bridges 2014 Predictions: What to Watch for in 2014
• SolarWinds 2014 Predictions: Commoditization Allows Innovation
• CA Technologies 2014 Predictions - In 2014 Cloud Computing is So Last Year
• Acronis 2014 Predictions: Security Demands to Drive Innovation in Cloud Storage
• Parallels 2014 Predictions – Cloud Management Platform Leaders Continue to Evolve

Настала пора посмотреть, какие темы в этом году в сфере виртуализации были у нас самыми актуальными и собрали больше всего просмотров. Поэтому мы просто сделали запрос к нашей базе и вывели статьи этого года, упорядоченные по количеству просмотров по убыванию.

Итак, как выглядит наш Топ-10 2013 года:

Неудивительно, что самым ожидаемым релизом этого года оказалась платформа виртуализации VMware vSphere 5.5. Каждый раз, когда выходит обновление vSphere, это делает маленькую революцию в сфере виртуализации. Ведь частные облака по-прежнему удерживают внимание ИТ-специалистов, и хост-платформа ESXi является лидирующим решением для построения корпоративных облачных инфраструктур.

Из технологий, которые оказались самыми интересными в vSphere 5.5 - это, конечно же, сервисы Virtual SAN, концепция Software Defined Networking (SDN) и продукт VMware NSX на ее основе, а также технология VMware Virtual Flash (vFlash).

Самый оживленный интерес вызвала именно версия View 5.2, у которой в названии добавилось еще слово Horizon, обозначающее принадлежность продукта к семейству решений из множества EUC (End User Computing).

Тут безусловные лидеры по интересу пользователей - функции 3D-графики в виртуальных ПК и технология Clientless HTML5 Access to View Desktops & Apps, позволяющая получать доступ к своим десктопам через браузер. Напомним, что не так давно вышла версия View 5.3, где функции по работе с 3D-графикой были значительно улучшены.

Как показывает статистика, тема переноса физических серверов в виртуальную среду по-прежнему актуальна. В статье рассказывается об основных аспектах процесса миграции P2V (Physical to Virtual) и средстве для автоматизации этого процесса - VMware Converter Standalone.

Оказывается, многим пользователям хочется подключить том VMFS к Windows-системе, чтобы скопировать его виртуальные машины, а далее заглянуть в содержимое их файлов виртуальных дисков (VMDK). Это возможно средствами драйвера Open Source VMFS Driver от fluid Ops. Жалко, что это средство поддерживается только для VMFS 3 и уже давно не обновляется.

Похвально, что тяга к знаниям находится у наших ИТ-специалистов так высоко. Скорее всего, заметка набрала много просмотров из-за того, что ссылку на нее часто пересылали.

Помимо решения для виртуализации настольных ПК VMware View, комплект Horizon Suite включает в себя VMware Horizon Mirage 4.0 - решение для управления образами рабочих станций пользователей, а также VMware Horizon Workspace 1.0 - комбинацию двух продуктов - Horizon Data (бывший Project Octopus - решение а-ля корпоративный Dropbox, о котором мы много писали вот тут) и Horizon Application Manager - решение для федерации SaaS-приложений и VDI-сервисов.

Тема резервного копирования хостов конфигурации хостов ESXi всегда востребована. Текущая версия этой утилиты (1.2) вышла в конце февраля этого года. Жаль, что не обновляется.

Конечно же, выпуск решения номер 1 для резервного копирования и репликации Veeam Backup and Replication 7 стал одним из главных событий этого года.

О каждой из новых функций решения можно почитать по этим ссылкам:

• Поддержка решения VMware vCloud Director (возможность №1)
• Плагин для vSphere Web Client (№2)
• Восстановление объектов Microsoft SharePoint (№3)
• Поддержка ленточных библиотек (№4)
• Поддержка виртуальных лабораторий по запросу (On-Demand Sandbox) для Hyper-V (№5)
• Улучшенный 1-Click Restore (№6)
• Виртуальные лаборатории для реплик (№7)
• Копирование резервных копий в географически удаленное хранилище по WAN-соединению (№8)
• Резервное копирование виртуальных машин из снапшотов, сделанных на уровне хранилищ (№9)

Действительно, полезный и нужный продукт.

Кто-то предрекал XenServer скорую смерть (в том числе, и мы), но он оказался живее всех живых. Citrix решила передать платформу XenServer сообществу Open Source, что может вдохнуть вторую жизнь в этот многострадальный продукт.

Действительно интересный пост наших коллег из компании ИТ-ГРАД, в котором рассказывается о Cisco UCS Manager, с помощью которого производится настройка всей системы. Данную задачу специалисты ИТ-ГРАД выполнили в рамках подготовки к тестированию FlexPod (Cisco UCS + NetApp в режиме MetroCluster) для одного из заказчиков.

На этом наш хит-парад закончен. Странно, что в него не попали статьи про новый Hyper-V (например, "Что нового будет в Hyper-V обновленного Windows Server 2012 R2", 12 место по популярности), но это объясняется, скорее всего, тем, что нас читают, в основном, любители VMware. Что ж, будем исправляться и поднажмем на заметки о решениях компании Microsoft, тем более, что она потихоньку откусывает свою долю рынка у VMware.

Всего в этом году у нас появилось 447 заметок о виртуализации и решениях для управления виртуальной инфраструктурой. Будем ждать вас уже в следующем году! С Наступающим Новым годом!

Мы уже много писали о технологии VMware Virtual SAN (VSAN), которая позволяет создать отказоустойчивый кластер хранилищ для виртуальных машин на основе комбинации SSD+HDD локальных дисков серверов VMware ESXi. Не так давно вышла обновленная бетаэтого решения, кроме того мы не так давно писали о производительности VSAN тут.

В этой заметке (на базе статьи Дункана) мы поговорим о том, как кластер VSAN обрабатывает сбои различного типа, и как происходит восстановление работоспособности виртуальной машины без ее простоя.

Итак, в нормальном режиме функционирования, при значении параметра FailuresToTolerate равном 1, который означает, какое количество отказов хостов может пережить кластер хранилищ, реплика одного VMDK будет размещена на дисках еще одного из хостов кластера:

Тут можно заметить 5 особенностей кластера VMware VSAN:

• Виртуальный диск VMDK и его реплика всегда находятся на разных хост-серверах VMware vSphere.
• ВМ не обязательно должна исполняться на том хосте ESXi, на дисках которого находятся ее хранилища.
• Компонент witness находится на третьем по отоношению к виртуальному диску и его реплике хосте, чтобы создать определенность на случай разделения сети VSAN (где окажется 2 компонента из набора "vmdk-реплика-witness" - тот сегмент и будет определяющим).
• Сеть VSAN используется для операций ввода-вывода и определения доступности.
• Реплика VMDK-диска вместе с основной копией образуют RAID-1 массив, который увеличивает производительность операций чтения в виртуальной машине, так как для чтения используются оба хранилища.

Кроме того, вследствие особенностей реализации кластера VSAN, надо понимать, что команды ввода-вывода не применяются к диску данных виртуальной машины, пока не пришло подтверждение об их записи на реплике. Но подтверждение приходит не от HDD-диска, где находятся данные ВМ (это было бы очень медленно), а от SSD-диска, который используется как энергонезависимый Write Buffer для команд ввода вывода. Таким образом, этот буфер (и данные, само собой) зеркалирован в рамках дисковой группы на другом хосте ESXi.

Теперь рассмотрим различные виды сбоев в кластере VSAN.

1. Ломается диск дисковой группы, где исполняется виртуальная машина.

Выглядит это так:

В этом случае такой диск сразу же помечается как "degraded", а команды ввода-вывода перенаправляются на другой хост-сервер VMware ESXi. При этом виртуальная машина этого не замечает, так как переключается на работу с SSD-буфером/кэшем и HDD-дисками другого хоста мгновенно (данные на момент сбоя были синхронизированы, ничего не потерялось).

Одновременно с этим сразу же начинается процесс построения реплики на другом хосте ESXi в рамках его дисковой группы, при этом проверяется, достаточно ли там свободных дисковых ресурсов. Если их недостаточно, то механизм VSAN будет ожидать. Как только вы добавите диски/дисковые группы на хостах - сразу же начнется процесс построения реплики (до его окончания машина будет помечена как "degraded").

Тут надо отметить, что в degraded-состоянии скорость записи данных останется прежней, простоя не будет, а вот скорость чтения упадет до построения новой реплики, поскольку второй копии данных пока нет.

2. Отказывает хост VMware ESXi целиком.

В этом случае запускать процесс восстановления сразу же, конечно, не нужно - мало ли что могло случиться с хостом, например, его случайно перезагрузили, или временно пропало сетевое соединение.

В этом случае происходит ожидание в течение 60 минут, и если отказавший хост ESXi не оживет, то начнется процесс создания реплики виртуального диска VMDK на другом хосте. Это время можно изменить в расширенной настройке кластера VSAN.ClomRepairDelay, но пока не известно будет ли это поддерживаться со стороны VMware.

3. Отказ SSD-диска в дисковой группе.

В кластере VMware Virtual SAN поддерживается 1 SSD-диск и до 7 HDD-дисков в одной дисковой группе. Всего на один хост VMware ESXi поддерживается до 5 дисковых групп.

В данном случае Failure Domain - это вся дисковая группа, включающая в себя SSD-диск, который используется для двух типов операций:

• Read Cache (70% емкости) - безопасное кэширование операций на чтение. На SSD-диске хранятся наиболее часто используемые блоки, что уменьшает I/O read latency для ВМ.
• Write Buffering (30% емкости) - когда приложение внутри гостевой ОС пытается записать данные, оно получает подтверждение записи тогда, когда данные фактически записаны на SSD (не на HDD), таким образом твердотельный накопитель используется как буфер на запись, что небезопасно при внезапном пропадании питания или отказе хоста. Поэтому данные этого буфера дублируются на других хостах кластера и их SSD-дисках.

Таким образом, при отказе SSD-диска, виртуальная машина начинает использовать реплику на уровне всей дисковой группы на другом хосте VMware ESXi. Вот почему выгодно делать две дисковых группы 3HDD+1SSD, чем одну  6HDD+1SSD.

Вот, в общем-то, и все. Более подробно об использовании SSD-дисков, их производительности и ресурсе можно прочитать вот в этой статье.

Продолжаем рассказывать о решении StarWind iSCSI SAN, предназначенном для создания отказоустойчивых iSCSI-хранилищ для виртуальных машин (есть версия как для VMware, так и для Hyper-V).

Многих пользователей StarWind волнует вопрос о миграции хранилищ с Windows 2008 на Windows 2012 R2, которую они планируют сделать одновременно с обновлением на StarWind V8.

Вот простой алгоритм, как правильно обновить ОС узлов StarWind iSCSI SAN и (опционально) обновить сам продукт на новую версию:

1. Используя Replication manager, необходимо отсоединить все узлы-партнеры от устройств первого узла (StarWind1).
2. На этом узле (StarWind1) нужно установить новую ОС.
3. Далее нужно установить StarWind V6 на этом узле. 
4. Ко всем устройствам на StarWind1 нужно добавить их HA-партнеров через Replication manager и запустить синхронизацию.
5. Дождаться окончания синхронизации и соединиться с новыми таргетами.
6. Удалить всех HA-партнеров от второго (StarWind2) через Replication manager.
7. Установить новую ОС на StarWind2.
8. Установить StarWind V6 на StarWind2. 
9. Добавить партнеров ко всем HA-устройствам на узле StarWind2 через Replication manager.
10. Дождаться окончания синхронизации и соединиться с новыми таргетами.
11. Обновить StarWind V6 на StarWind V8, следуя вот этой процедуре.

Более подробно этому посвящена вот эта ветка форума StarWind.

Коллеги рассказали про интересный случай: создали RDM-диск для двух виртуальных машин MSCS-кластера "across boxes", подцепили его к виртуальным машинам на двух хостах ESXi, а производительность на нем упала до 10 МБ/сек, хотя этот диск находится на быстром FC-хранилище EMC VNX и скорость должна измеряться сотнями МБ/сек. При этом в качестве хост-платформы используется VMware vSphere 5.1.

Ответ оказался простым - для хранилищ EMC VNX хост ESXi выставляет политику путей по умолчанию Round Robin (балансировка по двум путям). При использовании кластера MSCS на кворумном диске вызываются SCSI-3 резервации. SCSI-3 резервация (registration) посланная по одному пути позволяет производить дальнейшие резервации или SCSI-команды только по этому пути.

А при использовании политики Round Robin, когда плагин PSP_RR переключает на другой путь, кластер MSCS получает ошибку и пробует сделать SCSI-3 резервацию повторно или выполнить другие команды.

Поэтому вместо политики Round Robin для конкретного хранилища и для данного RDM-диска надо использовать следующие политики путей (плагины PSP_MRU или PSP_FIXED), в зависимости от типа хранища. Они приведены в KB 1010041 и в таблице ниже:

Для того, чтобы выставить политику путей, нужно в разеле Storage в vSphere Client выбрать нужный HBA-адаптер и устройство, для которого создан RDM-диск, и из его контекстного меню выбрать пункт Manage Paths (это также можно сделать в свойствах виртуальной машины для диска):

После выставления корректной политики путей скорость для кворумного диска MSCS вырастет в разы. Кстати, если вы используете VMware vSphere 5.5 и выше, то такого поведения там уже нет, и все работает корректно.

О новых возможностях VMware vSphere 5.5 по поддержке кластеров MSCS мы уже писали вот тут.

На прошедшей не так давно конференции VMworld 2013 Europe компания VMware, среди прочего, анонсировала новые версии продуктов для управления, автоматизации и мониторинга ИТ-среды предприятия. Сегодня вышли финальные версии следующих решений:

• VMware vCenter Operations Manager 5.8 - средство комплексной визуализации производительности, ресурсов и работоспособности инфраструктуры, операционных систем и приложений. О нем в составе Operations Suite мы подробно писали вот тут.

• VMware vCloud Automation Center 6.0 - продукт для управления облачной инфраструктурой предприятия (SaaS, PaaS, IaaS) средствами единого решения, построенного поверх VMware vCloud Director (для IaaS-инфраструктуры) и разработанного на базе решения DynamicOps (бывший продукт Virtual Resource Manager, VRM). О нем мы уже писали вот тут.

Напомним основные новые возможности vCenter Operations Manager 5.8 (VCOPS):

• Monitor business critical applications - поддержка мониторинга бизнес-приложений, например, Microsoft Exchange Server и SQL Server.
• Monitor fiber channel storage - комплексный многоуровневый мониторинг FC-хранилищ.
• Monitor Hyper-v servers - полноценная поддержка мониторинга серверов Hyper-V.
• Monitor Amazon AWS services - поддержка мониторинга сервисов Amazon, включая EC2, Elastic Block Store, Elastic Map Reduce, Elastic Load Balancing и Auto Scaling Group средствами пакета AWS management pack. Данный MP работает совместно с Cloudwatch service (по REST API), предоставляемым Amazon.
• Поддержка средства VMware Log Insight для мониторинга инфраструктуры vCenter Operations Manager.

Release notes продукта vCenter Operations Manager 5.8 доступны по этой ссылке, а скачать его можно по этой.

Основные новые возможности vCloud Automation Center 6.0 (vCAC):

• Возможность для пользователей запрашивать различные приложения и отслеживать статус их развертывания (эта функция пришла из Application Director).
• Улучшенный механизм работы с политиками утверждения операций.
• Конечные пользователи могут откатывать системные обновления самостоятельно.
• Возможности связи решения со сторонними сервисами.
• Развертывание сервисов на базе политик.
• Новый Advanced Service Designer, предоставляющий обновленные средства проектирования пользовательских форм и рабочих процессов.
• Возможность интеграции с продуктом IT Business Management Standard Edition.
• Поддержка VMware vCloud Hybrid Service, в том числе выполнения административных задач с ВМ, размещенными там.
• Поддержка архитектуры OpenStack (в дополнение к существующим vSphere, vCloud Director, Amazon Web Services, Hyper-V, Kernel-based Virtual Machine, Citrix XenServer и различным интерфейсам управления физическими серверами).
• Доступ к виртуальным машинам через Remote Console.
• Поддержка динамического создания изолированных и маршрутизируемых сетей и балансировщиков нагрузки.
• Поддержка хранилищ VSAN для размещения виртуальных машин.
• Поддержка механизма Storage DRS.
• Поддержка служб LDAP.
• Улучшения Multi-tenancy (работа с несколькими организациями в одном окружении).
• Механизм Verb-oriented RESTFUL API в бета-версии.

Release notes продукта vCloud Automation Center 6.0 доступны по этой ссылке, а скачать его нельзя - надо связываться с VMware.

Продолжаем рассказывать о решении StarWind iSCSI SAN & NAS, предназначенном для создания отказоустойчивых iSCSI-хранилищ для виртуальных машин, которое скоро получит еще больше новых возможностей, о которых мы писали в посте про вторую бету продукта StarWind V8.

В октябре мы писали о том, что компания StarWind попала в шортлист награды Storage, Virtualization, Cloud (SVC) Awards 2013 сразу в двух номинациях: "Virtualization Management Product of the Year" и "Storage Virtualization Product of the Year".

Ну а недавно пришла новость о том, что продукт StarWind занял второе место в обеих этих категориях, с чем мы и сердечно поздравляем коллег!

Более подробно об этом можно прочитать в пресс-релизе компании StarWind.

Кстати, если ваша организация не из России (а, например, из Украины), и вы хотите приобрести продукты StarWind iSCSI дешевле, то сейчас действует предновогодняя скидка - до 30%.

При каждом релизе платформы виртуализации VMware vSphere неизменно возникают вопросы о том, что же изменилось в плане поддержки гипервизором ESXi кластеров Microsoft Clustering Services (MSCS). Напомним, что базовая информация об этом находится здесь.

Вот какие варианты развертывания кластеров MSCS для различных приложений поддерживает VMware vSphere 5.5 (напомним, что о кластерах MSCS мы писали тут, тут и тут):

А вот какие версии и конфигурации кластеров Microsoft поддерживаются для различных верси гостевых ОС Windows Server и VMware vSphere:

А теперь перейдем к нововведениям, касающимся поддержки MSCS в VMware vSphere 5.5:

1. Во-первых, к общему хранилищу узлов кластера MSCS может быть организован доступ по нескольким путям посредством политики Round Robin (модуль PSP_RR). Ранее это сделать было нельзя ввиду проблем со SCSI reservations. Теперь эта проблема решена.

Однако тут есть ограничения:

• Поддерживается только для гостевых ОС Windows 2008 и Windows 2012.
• Поддерживаются только конфигурации Cluster Across Boxes (CAB) и N+1. Системы "Cluster in a box" (CIB) используют Virtual Reservations.
• Общий диск (Quorum или Data) должен быть развернут в режиме pass-through RDM.

2. Во-вторых, появилась поддержка протоколов FCoE & iSCSI. Ранее полноценно в качестве общего хранилища для кластеров MSCS поддерживались только  хранилища Fibre Channel, с оговорками iSCSI и как-то частично FCoE. Теперь же полноценно можно использовать iSCSI и FCoE хранилища.

А именно:

• Все конфигурации кластеров: CAB, CIB и N+1 поддерживаются iSCSI.
• Поддержка адаптеров iSCSI:
  
  • Software iSCSI;
  • Аппаратные адаптеры QLogic, Emulex и Broadcom.
• Поддержка режима Mixed mode для iSCSI-инициатора.
• До 5 узлов в кластере поддерживается для Windows 2008 SP2 и более поздних версий.

3. В-третьих, появилась поддержка кластеризации гостевых ОС Windows 2012 MSCS.

Если все это обобщить, то получится картинка, взятая отсюда:

Больше подробностей о поддержке MSCS в VMware vSphere 5.5 можно узнать из KB 2052238.

Как многие знают, в VMware vSphere 5.5 появились возможности Virtual SAN, которые позволяют создать кластер хранилищ для виртуальных машин на основе комбинации SSD+HDD локальных дисков серверов VMware ESXi. Не так давно вышла обновленная бета этого решения, кроме того мы не так давно писали о производительности VSAN тут и тут.

Сегодня же мы поговорим о том, как нужно сайзить хранилища Virtual SAN в VMware vSphere, а также немного затронем тему отказоустойчивости. Более детальную информацию можно найти в VMware Virtual SAN Design & Sizing Guide, а ниже мы расскажем о подходе к планированию хранилищ VSAN вкратце.

Объекты и компоненты Virtual SAN

Начнем с простого ограничения по объектам (objects) и компонентам (components), которое есть в VSAN. Виртуальные машины, развернутые на vsanDatastore, могут иметь 4 типа объектов:

• Домашняя директория виртуальной машины Virtual Machine ("namespace directory").
• Объект файла подкачки - swap object (для включенной ВМ).
• Виртуальный диск VMDK.
• Дельта-диски для снапшотов. Каждый дельта-диск - это отдельный объект.

Каждый объект, в зависимости от типа RAID, рождает некоторое количество компонентов. Например, один VMDK, размещенный на двух томах страйпа (RAID 0) рождает два объекта. Более подробно об этом написано вот тут.

Так вот, ограничения тут следующие:

• Максимальное число компонентов на 1 хост ESXi: 3000.
• Максимальное число компонентов для одного объекта: 64 (это включает в себя тома страйпов и также реплики VMDK с других хостов).

На практике эти ограничения вряд ли актуальны, однако о них следует знать.

Сколько дисков потребуется для Virtual SAN

Во второй бета-версии VSAN (и, скорее всего, так будет в релизной версии) поддерживается 1 SSD-диск и до 7 HDD-дисков в одной дисковой группе. Всего на один хост VMware ESXi поддерживается до 5 дисковых групп. Таким образом, на хосте поддерживается до 5 SSD-дисков и до 35 HDD-дисков. Надо убедиться, что контроллеры хоста поддерживают необходимое количество дисков, а кроме того нужно проверить список совместимости VSAN HCL, который постоянно пополняется.

Также надо учитывать, что кластер хранилищ Virtual SAN поддерживает расширение как путем добавления новых дисков, так и посредством добавления новых хостов в кластер. На данный момент VMware поддерживает кластер хранилищ максимум из 8 узлов, что суммарно дает емкость в дисках в количестве 40 SSD (1*5*8) и 280 HDD (7*5*8).

Сколько дисковой емкости нужно для Virtual SAN (HDD-диски)

Необходимая емкость под размещение VMDK зависит от используемого параметра FailuresToTolerate (по умолчанию 1), который означает, какое количество отказов хостов может пережить кластер хранилищ. Если установлено значение 1, то реплика одного VMDK будет размещена на дисках еще одного из хостов кластера:

Тут можно сказать о том, как работает отказоустойчивость кластера Virtual SAN. Если отказывает хост, на котором нет виртуальной машины, а есть только VMDK или реплика, то виртуальная машина продолжает работу с основной или резервной копией хранилища. В этом случае начнется процесс реконструкции реплики, но не сразу - а через 60 минут, чтобы дать время на перезагрузки хоста (то есть если произошел не отказ, а плановая или внеплановая перезагрузка), а также на короткие окна обслуживания.

А вот если ломается хост, где исполняется ВМ - начинается процедура восстановления машины средствами VMware HA, который перезапускает ее на другом хосте, взаимодействуя при этом с Virtual SAN.

Более подробно этот процесс рассмотрен вот в этой статье и вот в этом видео:

Однако вернемся к требующейся нам емкости хранилищ. Итак, если мы поняли, что значит политика FailuresToTolerate (FTT), то требуемый объем хранилища для кластера Virtual SAN равняется:

Capacity = VMDK Size * (FTT + 1)

Что, в принципе, и так было очевидно.

Сколько дисковой емкости нужно для Virtual SAN (SSD-диски)

Теперь перейдем к SSD-дискам в кластере VSAN, которые, как известно, используются для вспомогательных целей и не хранят в себе данных виртуальных машин. А именно, вот для чего они нужны (более подробно об этом тут):

• Read Cache - безопасное кэширование операций на чтение. На SSD-диске хранятся наиболее часто используемые блоки, что уменьшает I/O read latency для ВМ.
• Write Buffering - когда приложение внутри гостевой ОС пытается записать данные, оно получает подтверждение записи тогда, когда данные фактически записаны на SSD (не на HDD), таким образом твердотельный накопитель используется как буфер на запись, что небезопасно при внезапном пропадании питания или отказе хоста. Поэтому данные этого буфера дублируются на других хостах кластера и их SSD-дисках.

Так каковы же рекомендации VMware? Очень просты - под SSD кэш и буфер неплохо бы выделять 10% от емкости HDD-дисков хоста. Ну и не забываем про значение FailuresToTolerate (FTT), которое в соответствующее число раз увеличивает требования к емкости SSD.

Таким образом, необходимая емкость SSD-хранилищ равна:

Capacity = (VMDK Size * 0.1) * (FTT + 1)

Ну и напоследок рекомендуем отличнейший список статей на тему VMware Virtual SAN:

• VSAN Part 1 – A first look at VSAN
• VSAN Part 2 – What do you need to get started?
• VSAN Part 3 – It is not a Virtual Storage Appliance
• VSAN Part 4 – Understanding Objects and Components
• VSAN Part 5 – The role of VASA
• VSAN Part 6 – Manual or Automatic Mode
• VSAN Part 7 – Capabilities and VM Storage Policies
• VSAN Part 8 – The role of the SSD
• VSAN Part 9 – Host Failure Scenarios and vSphere HA interop
• VSAN Part 10 – Changing VM Storage Policy on-the-fly

На oszone.net вышла интересная статья, касающаяся развертывания агента StarWind SMI-S Agent под средство управления виртуальной инфраструктурой Microsoft Hyper-V - System Center Virtual Machine Manager (VMM). Напомним, что этот агент позволяет из консоли VMM управлять хранилищами виртуальных машин StarWind Native SAN for Hyper-V, в том числе хранилищами в бесплатной версии StarWind.

;

Скачать StarWind SMI-S Agent можно по этой ссылке, а в статье "Опыт использования SMI-S для автоматизации управления StarWind iSCSI SAN Free в System Center Virtual Machine Manager 2012 SP1" подробно написано о том, как его правильно развернуть и начать использовать.

Используя компонент StarWind SMI-S для SC VMM вы сможете создавать, удалять и настраивать виртуальные хранилища StarWind таким образом, что вам почти никогда не придется запускать StarWind Management Console.

;

Также на эту тему рекомендуем документ "StarWind SMI-S Agent: Storage Provider for SCVMM", где описаны основные шаги установки этого агента и настройки SC VMM.

Мы уже писали о технологии VMware Virtual SAN, которая сейчас находится в режиме бета-тестирования. Кроме того, мы затрагивали тему производительности виртуальных ПК VMware Horizon View на хранилищах Virtual SAN (там про то, что VSAN масштабируется почти без потерь производительности).

Сегодня мы хотим рассказать еще о двух вещах. Во-первых, компания VMware выпустила обновление беты Virtual SAN, которое получило следующие новые возможности:

• AHCI fix - как писала VMware ранее, была проблема с контроллерами AHCI, которая приводила к потере данных на устройствах VSAN (см. PDL, Permanent Device Loss). Теперь эту проблему исправили, и можно продолжать тестирование на этих контроллерах.

• New RVC Commands - теперь в Ruby Virtual Console, которая входит в состав VMware vCenter 5.5, есть команды по управлению хранилищами в пространстве имен spbm (Storage Policy Based Management). Существующие политики можно найти в папке "~/storage/vmprofiles".

• PowerCLI fling - многим пользователям интересна автоматизация задач в VMware vCloud Suite. Теперь и для VSAN есть набор командлетов PowerCLI, которые позволяют управлять хранилищами VSAN. Более подробно об этом здесь.

• Limit Changes - в первой бета-версии дисковая группа могла иметь 1 SSD-Накопитель и до 6 HDD-дисков, но поскольку есть серверы, в которых восемь слотов, то HDD-дисков теперь поддерживается до 7 штук (SSD по-прежнему один).

Во-вторых появилась третья статья в серии про Virtual SAN - "VDI Benchmarking Using View Planner on VMware Virtual SAN – Part 3" из цикла статей, где делаются всяческие замеры производительности хранилищ VSAN.

В этот раз сравнивалось некий дисковый массив "all flash storage array", который работает на SSD-накопителях, и 7-ми и 8-ми узловые кластеры Virtual SAN. Результаты в очках, поставленных VDImark (View Planner QoS), поставленные кластеру из хостовых хранилищ и дисковому массиву:

Напомним, что очки VDImark - это число виртуальных машин, которое может быть запущено на данной аппаратной конфигурации с соблюдением определенного порогового значения для операций (на самом деле минимум 95% операций должны попасть в эти трешхолды для ВМ, чтобы их засчитали).

Результаты тестов оказались весьма неплохими. Картинка для тестов по времени отклика операций группы А (интерактивные операции пользователя):

Группа B:

Вывод: Virtual SAN - очень неплох в сравнении с нативной производительностью какого-то SSD-массива (VMware, что это за массив-то??).

Ну и ссылки на все статьи цикла:

• VDI Benchmarking Using View Planner on VMware Virtual SAN – Part 1
• VDI Benchmarking Using View Planner on VMware Virtual SAN – Part 2
• VDI Benchmarking Using View Planner on VMware Virtual SAN – Part 3

Не так давно мы писали про новые возможности VMware Horizon View 5.3 - одного из лидирующих решений на рынке виртуализации корпоративных ПК. Несколько дней назад этот продукт стал доступен для скачивания (линк на загрузку).

Напомним, что основной ожидаемой новой возможностью VMware Horizon View 5.3 стала полноценная поддержка 3D-графики в виртуальных ПК в режиме vDGA (пока только для карт NVIDIA).

Напомним вкратце о новых возможностях VMware View 5.3 (полный список - тут и в Release notes):

• Windows Server 2008 R2 Desktop Operating System Support - возможность использовать эту ОС для виртуальных ПК, что интересно для тех организаций, который хотят предоставлять виртуальные ПК в аренду (кастомизировав серверную ОС под десктопную, так как Microsoft запрещает предоставление в аренду настольных ОС).
• Поддержка Windows 8.1 для виртуальных ПК.
• Использование VMware Horizon Mirage для управления десктопами View (подробнее - тут).
• Поддержка технологии Virtual SAN и таких хранилищ для десктопов (по-прежнему, в бета-режиме).
• Memory Recommendation messages - возможность получения рекомендаций для сайзинга по памяти Connection Server.
• Полноценная поддержка режима Virtual Dedicated Graphics Acceleration (vDGA).
• Улучшения механизма связанных клонов - теперь для пула Linked-Clone доступна политика Storage Overcommit.
• View Persona Management Supportability Improvements - улучшения режима виртуализации пользовательских профилей.
• Возможность добавлять группу "Администраторы" к перенаправляемым механизмом Persona Management папкам.
• Плагин View Agent Direct-Connection Plug-in - возможность организовать прямое соединение по протоколу PCoIP между клиентом и виртуальным ПК, минуя View Connection Server.
• View Composer Array Integration Support - полноценно поддерживается технология View Composer API for Array Integration (VCAI), которая позволяет передать часть операций по работе с виртуальными ПК на сторону дискового массива.
• Поддержка до 350 соединений для шлюза Blast Secure Gateway.
• VMware ThinApp 5.0 - обновленная версия средства для виртуализации приложений.
• Клиент VMware View Client 2.2 при использовании ОС Linux теперь может работать с аудио/видео-потоком.
• Поддержка Multimedia Redirection для десктопов Windows 7
• Обновленный HTML Access в составе Horizon View 5.3 Feature Pack (куча улучшений)
• Flash URL Redirection - перенаправление swf-потока на клиентское устройство.
• Режим Unity Touch теперь поддерживается для Windows Server 2008 R2 и Windows 8.1.
• USB 3.0 redirection support - возможность перенаправления таких устройств в виртуальные ПК.
• Поддержка БД Oracle 11.2.0.3.

Кроме этого, были обновлены все клиенты VMware View до версии 2.2 (теперь поддерживается iOS 7). Вот документация по этим клиентам, где можно узнать о новых возможностях каждого:

•  iOS
• Android
• Mac OS X
• Linux
• Windows
• Windows Store
• HTML Access (Blast)

Теперь официальные документы по Horizon View 5.3:

• What’s New in VMware Horizon View 5.3
• Using VMware Horizon View Client for Windows (View 5.3)
• VMware Horizon View Feature Pack Installation and Administration (View 5.3)
• Using VMware Horizon View HTML Access (View 5.3)
• VMware Horizon View Agent Direct-Connection Plugin Administration (View 5.3)

Остальные документы еще не обновились.

Интересное видео по настройке View 5.3 совместно с хранилищами VSAN:

И на эту же тему интересная статья - Horizon View 5.3 Storage Optimization Features–Deep Dive.

Прямое соединение по PCoIP:

Скачать VMware Horizon View 5.3 можно по этой ссылке.

С выходом обновленной версии платформы виртуализации VMware vSphere 5.5 компания VMware ввела новую модель Native Device Driver Architecture, которая позволяет использовать нативные драйверы для VMkernel вместо драйверов под Linux.

Однако, помимо этого нововведения, VMware также убрала и неофициальную поддержку многих SATA-контроллеров, которые раньше и не заявлялись как работающие, но вполне нормально функционировали на whitebox-конфигурациях (например, контроллеры ASMedia и Marvell). Теперь многие SATA-контроллеры в ESXi 5.5 просто не работают.

Но не все так плохо. Поскольку поддержка старой модели драйверов еще осталась (неизвестно будет ли она в следующей версии ESXi, но скорее всего будет, так как не все партнеры успеют перейти на новую модель), то можно заставить работать некоторые неподдерживаемые контроллеры SATA AHCI, поскольку сам драйвер AHCI остался в виде модуля VMkernel (ahci). Andreas Peetz не только написал хорошую статью о том, как это сделать, но и сделал кастомные VIB-пакеты для добавления поддержки некоторых SATA-контроллеров AHCI.

Суть такая - автор раньше думал, что команда vmkload_mod ahci заставляет ESXi загружать драйверы для всех обнаруженных PCI-устройств, то оказалось, что она конфигурирует только устройства, которые есть в файле /etc/vmware/driver.map.d/ahci.map. А там неподдерживаемых девайсов не появляется. Поэтому надо сделать отдельный map-файл и добавить ссылки соответствующих устройств (их PCI ID) на драйвер AHCI.

Андреас сделал VIB-пакет позволяющий добавить поддержку ESXi следующих SATA-контроллеров:

• ASMedia Technology Inc. ASM1061 SATA IDE Controller (1b21:0611)
• ASMedia Technology Inc. ASM1062 Serial ATA Controller (1b21:0612)
• Marvell Technology Group Ltd. 88SE9123 PCIe SATA 6.0 Gb/s controller (1b4b:9123)
• Marvell Technology Group Ltd. 88SE9172 SATA 6Gb/s Controller (1b4b:9172)

В каментах Андреас принимает заявки на добавление поддержки нужных SATA-контроллеров, так что если их в приведенном выше списке - пишите ему и он добавит.

Процедура добавления поддержки контроллеров такова. Добавляем возможность использования кастомных драйверов на ESXi:

esxcli software acceptance set --level=CommunitySupported

Разрешаем использование http на хосте в фаерволе:

esxcli network firewall ruleset set -e true -r httpClient

Устанавливаем VIB-пакет:

esxcli software vib install -v https://esxi-customizer.googlecode.com/files/sata-xahci-1.0-1.x86_64.vib

Пакет sata-xahci предоставляется как в виде VIB-файла, так и в виде Offline Bundle. Включить драйверы в состав установщика ESXi можно с помощью инструментов ESXi-Customizer или ESXi-Customizer-PS.